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4.0 CONCLUSIONS AND RECOMMENDATIONS 

The cost drivers (CDs) were combined into baselines as a way of summarizing 
the results of the study of the cost drivers. The resulting baselines are shown in Table 
4.0-1. This table (combined with the details in section 3.2) provides answers to the 
ongoing PTC/SCS cost tradeoff efforts. The four baselines are: 

• Cost Effective - This is the recommended, most cost effective baseline. Where 

there is a reasonable pay back, higher development costs are traded for 
lower operations costs (CD #s 6, 10, 16, & 24) Training capabilities that cost 
some more, but would enhance training in a significant way are added in 
(CD #s 17, 18, 27, & 28). This baseline also reflects recommendations for 
use in the PTC/SCS that are technically possible and would lower 
operations cost for a reasonable increase in development cost (CD #s 7, 23, 
& 33), but have not been followed by SSFP (ITVE or SSTF). It also differs by 
changing some of the impractical assumptions made to reduce costs to the 
CBR baseline, and then makes a cost effective (again trading development 
cost for operations cost) provision to cover these (CD #s 1 1 & 1 5). 

• CBR - The CBR baseline includes three DMS Kits, non-DMS Kit PTTs, IP 
PTTs, (JEM and ESA, only one of which runs at a time), and an IT&V facility, 
and a development facility. ITVE and SSE will be used. 

• Low Cost - This is a variation of the CBR baseline. The CBR baseline is 
already as low a cost high fidelity trainer that can support the estimated flow 
of payloads and trainees. For the Low Cost baseline, choices have been 
made that trade a slightly higher development cost for lower operations cost 
(CD #s 10 & 24). This baseline also reflects recommendations for use in the 
PTC/SCS that are technically possible and would lower operations cost for a 
reasonable increase in development cost (CD #s 7, 23 & 33), but have not 
been followed by SSFP (ITVE or SSTF). It also differs by changing some of 
the impractical assumptions made to reduce costs to the CBR baseline, and 
then makes a low cost provision to cover these (CD #s 1 1 & 1 5). 

• Low Fidelity, Low Cost - This is designated as the absolute lowest cost 
PTC/SCS. It is also, at best, a medium fidelity simulator. It will not support 
flight equivalent payloads or payload flight software. All Spacelab PCTC 
experience indicates a trend toward more flight equivalent hardware and 
software, not less. Also, there is some risk in this approach that the payload 
training would be inadequate with potentially botched experiments and 
wasted valuable on-orbit time. It achieves some of its savings by trading 
lower development cost for higher operations cost. With this design, there is 
little possibility of realistic on-orbit payload problem solving assistance from 
the PTC/SCS. 

The ground rules used in arriving at all four of the baseline solutions are the 
same as those stated in Appendix 1 and 2 of the SCS Overview and Summary Report 
from October 1989, with the following exceptions: 
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A. POIC training is assumed to be a POIC function. To reduce PTC/SCS cost, 
the separate PTC POIC training host and software were removed. This is in 
line with CBR, and operational experience that indicates a significant portion 
of the POIC training will be on the job training (OJT) due to the 24 hours per 
day 365 days per year POIC SSF operations at AC. 

B. The extensive training analysis done by the SCS team was utilized to 
develop the proposed PTC/SCS baseline architectures. For the baselines, 
the number of concurrent sessions are as follows: 

• 2 US Lab Modules 

• 1 Development Unit Test 

• 1 IT&V 

• 1 International Partner's PTT Individual Training 

• 3 PTT Individual Payload Training 

C. No real-time training interface capability to the SSTF is provided. (Study 
Issue Assumption # 20) 

D. OMGA and MPS will not run on the SCS, but will supply the needed 
information to support payload training. (Study Analysis Assumption # 3) 

E. Crew and payload rotation will be no more often than every 90 days. 

Each of these baselines will be discussed in following sections. 
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Table 4.0-1 OPTION COMPARISONS FOR COST DRIVERS 


COST DRIVER 

LOW Fi LOW 
COST 

LOW COST 

CBR 

BASELINE 

COST 

EFFECTIVE 

1-C&D Panel 

b- virtual 

a-custom 

a-custom 

a-custom 

2-MPAC 

b-sim. 

a-F/E 

a-F/E 

a-F/E 

3-P/L Fidelity 

b-blk. box 

a- full 

a-full 

a-full 

4-Core Model Fidelity 


a-F/E 

EonniEHi 

a-F/E 

5-Environment Fidelity 


a-full 


a-full 

6-DMS Kit Use 

d-sim. 

a-all tmrs 

b-mod. trnr 

a-all tmrs 

7-S IB/Host l/F 

None 

b-LAN 


EEmZFMM 

8-MDM Use 

None 

a-DMS 

a-DMS 

a-DMS 

9-OMGA Use 

None 

a-F/E 

a-F/E 

a-F/E 

10-Concurrent Sessions 

all non-DMS 

a-2+3Lo+1 

b-2+3non+1 

c-2+3+1 +1 

11 -Flight Equivalent Payloads 

c-0% 

b-10% 

40%+0% 

a-40% 

12-Trainees & P/Ls per Qutr. 

BESEEM 




1 3-P/L Changeout / Increment 

d-5%* 




14-DIF Representation 

c-none 

b-static 

b-static 

b-static 

15-P/L Models built at PTC 

c-0% 

b-25% 

c-0% 

a-50% 

16-P/L Remote Development 

c-none 

c-none 

c-none 

b-50% 

17-Consolidated Inc.Training 

c-none 

c-none 

c-none 

b-limited 

18-POIC Interface 

b-limited 

b-limited 

b-limited 

a-full 

19-Train UOFs/ROCs/DOCs 

c-none 

a-via POIC 

a-via POIC 

a-via POIC 

20-MODB/RODB Use 

c-not used 

a-all 

a-all 

a-all 

21 -Use of Ada 

c-none** 

a-all 

a-all 

a-all 

22-Use of SSE/ITVE 

c-none 

a-all 

a-all 

a-all 

23-P/L Model Trans, to SSTF ; 

b-convert 


ES 


24-Model Trans.- PTT<->Mod. 


a-same h/w 

d-none 

a-same h/w 

25-Attached P/L Rep. 

b-in mod trnr 

b-in mod trnr 

b-in mod trnr 

b-in mod trnr 

26-P/L Video Representation 

b-canned 

LS^MliiUSI 

LEsi’iiMuiaK 

EM 

27-F/E P/L GSE 

b-limited 

b-limited 

b-limited 

a-full 

28-P/L Stimulation 

c-none 

b-limited 

b-limited 

a-full 

29-Instructors per Trainer 

a-1 

b-4 

b-2 

b-4 

30-US P/Ls in IP Modules 

b-sim IP Kits 

a-IP Kits 

a-IP Kits 

a-IP Kits 

31 -Host Reconfigurability 

c-none 

b-reconfig 

b-reconfig 

b-reconfig 

32-Malfunction Insertion 



rmuaw-rm 

1 1 1IBIII If M 

33-Simulator Modes 

b- med/5 

b- med/5 

c-low/2 

rBilHlT/JMI 

34-Session Data Handling 

b-limited 

a-full 

a-full 

| a-full 


* = Same for all baselines. These cost drivers have a large affect on cost and 
were explored for this reason. The current manifests were used for 
comparison for the four baselines. 

** = Choice of language would be dictated by host machine and which 
language the programmers knew best to cut the development cost. 
Operations cost would be higher and synergism between centers is lost. 
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4.1 COST EFFECTIVE SOLUTION 

In this section the best, most cost effective solution for supporting SSF payload 
training at assembly complete (AC) in the PTC is described and discussed. Several 
other related design alternatives are shown in section 4.5 "Other Designs" to illustrate 
other ideas resulting from the process of developing the various baselines. 

Figures 4.1-1 and 4.1-2 illustrate the best, most cost effective solution for 
meeting the baseline PTC training requirements. 

The advantages of the Cost E ffective baseline design arei 

• High fidelity training and support of the PDRD training requirements. 

• Low cost. No non-DMS trainers, which eliminates the cost of the hardware 
and software needed to simulate the DMS functions. 

• No problems or extra cost in migrating payload models from the PTTs to the 
Module Trainers. 

• No problems transporting payload models from the PTC to the SSTF if the 
SSTF P/L session host is the same as the SCS hosts. 

• Excellent failure recovery. If required, the detailed design could easily make 
short recovery times for all functions (training, development, and IT&V) 
possible. Dual ported disks, shared memory, and computer controlled 
switches can be added to provide the capability to reconfigure, utilizing other 
available SCS resources. 

• Functions are totally separable. Training, development, and IT&V can be 
completely separated for scheduling and operating purposes. Trainees will 
not arrive to find a trainer down for some development problem. 

• Low design risk. The SCS Study Team has high confidence that this design 
can support the baseline amount of required training, and that the design 
can be implemented, i.e. no loading, cable length, or network problems will 
necessitate a major design rework. 

• JEM & ESA PTTs can be operated independently of each other. 

• Online CBT. 



MODULE TRAINER MODULE TRAINER 
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Figure 4.1-1 . Seven Kit Local Host Design 
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Figure 4.1-2. PTT Racks Driven by Three DMS Kits 
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4.2 CBR BASELINE 

The ground rules used in arriving at the CBR baseline solution are the same as 
those used for the other baselines (see section 4.0), with the following exceptions: 

A. Per CBR, Consolidated Increment Training was removed as a requirement 
on the PTC. 

B. Per CBR, International Partner Lab Module training has been removed as a 
requirement on the PTC. Only US payloads in the International Partner 
Labs will be trained at the PTC. 

Since the current Level II DMS Kit database shows three DMS Kits allocated for 
the PTC, this was used to derive the CBR baseline. Several other different designs 
are shown in Section 4.5 to provide a picture of the tradeoffs made to meet CBR. The 
current design in place as a result of CBR is shown in Figure 4.2-1. 

The number of concurrent sessions that could be supported by three kit designs 
varies with the design, but a typical snapshot yields: 

• 1 US Lab Module 

• 1 Attached Payload Training Session (non independent) 

• 0 Development Unit Test (Unit test is done in spare Module Trainer time) 

• 1 IT&V 

• 1 International Partner's PTT Individual Training 

• 2 PTT Individual Payload Training 

A non-DMS design for all PTTs was utilized as shown in Figure 4.2-1 , the 
current CBR design. This cuts the design risk, but generates the problem of moving 
payload models from a simulated DMS environment to a real DMS Kit environment. It 
also raises the cost if a high fidelity non-DMS trainer is built, since a high fidelity DMS 
simulator will not be cheap to develop. The current baseline has a low to medium 
fidelity DMS simulator meaning that it does not support flight equivalent payloads nor 
payload flight software. 
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4.3 LOW COST BASELINE 

The ground rules used to arrived at the Low Cost solution are the same as 
those for the CBR baseline except: 

A. For the low cost solution, the number of concurrent sessions are as follows: 

• 2 US Lab Modules 

• 1 Attached Payload Trainer (non independent, attached to module 
trainer) 

• 0 Development Unit Test (Unit test is done in spare Module Trainer time) 

• 1 1T&V 

• 2 International Partner’s PTT Individual Training 

• 2 PTT Individual Payload Training 

B. The rate of payload change out, based on the May 1990 OSSA Payload 
Traffic Model is estimated to be 5% or less per increment. 

C. Significantly less crew hours per experiment will be needed, per 
conversations with the SpaceLab J training manager and WP01 training 
personnel. 

Figures 4.3-1 and 4.3-2 illustrate the Low Cost baseline design. Note that non- 
DMS Kit PTTs are shown on the design. These would only be needed if more than 
two concurrent PTT training sessions are required. The hardware and software 
needed to obtain the same high fidelity simulation capability is extensive - see section 

4.4 "Low Fidelity, Low Cost". Also note the appearance of a development LAN (DEV 
LAN), illustrating the need for unit test to share time on the module trainers, since a 
DMS Kit is not devoted to development. 

The advantages of the Low Cost design are: 

• High fidelity training and support of the PDRD training requirements. 

• Low cost. No non-DMS trainers, which eliminates the cost of hardware and 
software needed to simulate the DMS functions. Also, two less DMS Kits 
required than the Cost Effective design (5 total). 

• No problems in migrating payload models from the PTTs to the Module 
Trainers. 

• No problems in transporting payload models from the PTC to the SSTF. 

• Good failure recovery. If required, the detailed design could potentially 
make fairly short recovery times for all functions (training, development, and 
IT&V) possible. 
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Figure 4.3-1 Five Kit Local Host Design 
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Figure 4.3-2 PTT Racks Drvien by Two DMS Kits 
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Functions are mostly separable. Training, development, and IT&V can be 
mostly separated for scheduling and operating purposes. Probability is low 
that trainees will arrive to find a trainer down for some development problem. 

Moderate design risk. The SCS Study Team has good confidence, given 
the assumed loading constraints, that this design can support the reduced 
amount of required training, and that the design can be implemented, i.e. no 
loading, cable length, or network problems will necessitate a design rework. 
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4.4 LOW FIDELITY, LOW COST BASELINE 

As discused extensively in the SCS Study Report Volume 3, the "Refined 
Conceptual Design Report", a DMS Equivalent design is consistent with the 
architecture of the Local Host design. This DMS Equivalent design will provide the 
low fidelity, low cost baseline. 

Low fidelity here means that the design will not support flight equivalent 
payloads or payload flight software. Also, the MPAC would be different and virtual 
panels are used. Virtual panels would not have the look or feel of flight C&D panels. 
Their use would permit quick (in minutes) reconfiguration of a Lab Module trainer. 
This might, given a low enough flow of trainees, permit one (1) quick reconfiguration 
Lab Module to replace two (2) high fidelity Module trainers. However, training flow 
analysis done thus far shows that this is not possible. The development cost of one 
virtual panel Lab trainer might equal that of two high fidelity Lab trainers since virtual 
panels are not cheap. However, operations cost would be much less. The PTC 
Operations personnel would most likely have to build the virtual panel C&D displays, 
since this is specialized to the type of virtual panel employed. 

This design replaces the flight equivalent DMS Kit components with commercial 
general purpose microcomputers and custom software. ITVE and SSE functionality 
would have to be purchased in COTS software and hardware. There are potentially 
some cost savings to be had here since the necessary COTS hardware is relatively 
inexpensive compared to DMS Kit hardware. But based on the SCS Study Extension 
Task 5 experience, no DMS or DMS Kit software would be used. Porting this software 
to COTS hardware has proven to be difficult and expensive. Some modifications to 
the COTS hardware would be needed to permit flight equivalent software to be used. 
Figure 4.4-1 illustrates the updated DMS Equivalent design. 

There is the risk that the COTS hardware utilized will become obsolete and 
unavailable before the DMS Kit hardware does simply because NASA owns and 
controls the DMS Kit hardware. The Spacelab Computer Interface Devices (CIDs) are 
still operating today because they are a specialty item, much like the SIB part of the 
DMS Kits. If the CIDs had been COTS hardware, they would have become 
unavailable and non-maintainable years ago. 

If a DMS Equivalent design is utilized, there will also be additional operating 
cost required to update the simulation to follow the changes in the flight system. This 
will require design work, reviews, code, unit test, and l&T. If DMS Kits are utilized, 
updates will consist of installing an testing the new DMS Kit flight equivalent software. 
Also, a DMS Equivalent design includes schedule risk since the DMS CDR is currently 
scheduled for 1993. Needed detailed technical data would not be available when 
needed. For the Low Fidelity, Low Cost baseline, less software is needed to replace 
DMS than is shown in Section 3.2-6 "Use of DMS Kits". This is because flight 
equivalent payloads and payload flight software are not supported. 

Figure 4.4-2 illustrates the complexity of producing a high fidelity crew station 
MPAC utilizing COTS hardware. The 15" flat panel displays will run not only RGB 
displays, but display normal NTSC video in windows. These panels are not yet 
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commercially available, and will only be available from IBM or Toshiba, who are jointly 
developing this technology. Simply put, you can buy the DMS Kits from IBM, or you 
can by the parts from IBM, and build your own kits. It is not clear yet that the latter will 

be cheaper. 

An additional potential problem with the DMS Equivalent design is that of 
credibility with the astronaut trainees. If DMS Kits and fight software modified slightly 
to be flight equivalent are used for training, there will be little questioning by the crew 
of the results. If non-DMS hardware and non-flight software is utilized, the crew will 
challenge the training if something unplanned occurs. This happens now in Spacelab 
since the PCTC uses non-flight equivalent hardware and software. Even though the 
vast majority of the time the training is valid, the questions arise, and time is consumed 
verifying the training. This type of activity will be much less if flight equivalent 
hardware and software (DMS Kits) are used in training. 

However, if training can be done on a very different form, fit and look MPAC, 
cost savings in hardware may be achieved by using personal computers or 
workstations for MPACs. Three windows on a single screen would represent the three 
MPAC screens. A COTS joystick and trackball would be used instead of flight 
equivalent hardware. A COTS keyboard would be used, which might not match 
exactly the flight keyboard. Software to drive the simulated MPAC screen would have 
to be developed as opposed to using flight DMS MPAC software. These personal 
computers or workstations will be maintainable for a long time. The cost of following 
the flight designs and modifying and maintaining this software over the life of the SSF 
might add considerably to the operations costs. While the DMS Equivalent design has 
appeal in giving less dependency on elements beyond PTC control and potential cost 
savings, currently it is difficult to justify choosing it due to training fidelity issues. 
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Figure 4.4-2 MPAC Layouts from March '90 PDR 
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4.5 OTHER DESIGNS 

A number of other designs and options were considered during this very 
extensive baseline architecture effort. These pictures are printed here to aid future 
design discussions. The first, Figure 4.5-1 , illustrates the use of an eighth DMS Kit to 
support an independent Attached Payload trainer. This design has all the features 
and advantages of the seven kit design, plus the additional advantage of independent 
training of attached payloads. 

Figure 4.5-2 illustrates the nine PTT racks being driven by a current PTT sized 
DMS Kit (3 MDMs) and a non-DMS host. This would support about 30% flight 
equivalent payloads. It would only be needed if more than one independent PTT 
session is required. Otherwise, the design shown in Figure 4.5-8 "PTT Racks Driven 
by One DMS Kit" would suffice. If concern for failure of the single host indicates a 
second host, the second host could be added to the Figure 4.5-8 design with minimal 
extra cost for interfaces and switches, rather than go to the Figure 4.5-2 design. 

A higher percentage of flight equivalent payloads could be supported by 
utilizing one large DMS Kit for all nine PTT racks. The design shown in Figure 4.5-3 
has enough MDMs to support flight equivalent payloads in all payload racks. This 
design also has very poor failure tolerance. Also, note that by adding three SDPs and 
one SIB and some other DMS components, we have the equivalent of a second DMS 
Kit to support PTT training. Add a second host, and a much more fault tolerant design 
can be produced. 

Since the current Level II DMS Kit database shows three DMS Kits allocated for 
the PTC, several other three DMS Kit designs were done to explore the possibilities. 
The best one was selected for the CBR baseline. The others are here for reference. 

The features of the all DMS Kit design shown in Figure 4.5-4 are: 

• High fidelity training and support of the PDRD training requirements. 

• Medium cost. In designs with no non-DMS Kit trainers, which eliminates the 
cost of hardware and software needed to simulate the DMS functions, costs 
are somewhat offset by the special switches and cables required to produce 
these design. Also, four less DMS Kits required than the baseline design. 
However, if the reduced load is to be supported, non-DMS PTTs must be 
developed. 

• With the addition of non-DMS PTTs, there is high potential for problems in 
migrating payload models from the PTTs to the Module Trainers. 

• No problems in transporting payload models from the PTC to the SSTF. 

• Poor failure recovery. If one module DMS Kit fails, one half of training 
capability is lost. If non-DMS PTTs are used, this one third number gets 
smaller. 
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• Functions are not separable. Unit test would be done on the module 
trainers, probably in non-day shift hours. 

• High design risk. Unless non-DMS PTTs are used, cable lengths and the 
switches required present a high probability of design problems that could 
necessitate major design reworks midway through. If non-DMS PTTs are 
used, the technical problems of migrating payload models from simulated to 
real DMS Kits arises. 

More independent sessions can be supported via non-DMS PTTs. Considering 
the various three kit designs against the training loading analysis in section 1.2, it is 
clear that non-DMS PTTs will be needed to support the anticipated training load. 

The next three kit design in this section and the CBR design represent the end 
points of possible design options. The all DMS Kit design shown in Figure 4.5-4 
illustrates one of the potentially possible end points as it is an all DMS Kit design. To 
make this design possible, significant design assumptions (and thus risks) must be 
accepted. Assumptions associated with this design are: 

• Switches for all types of signals (analog, digital, video, audio) of varying 
rates can be produced. 

• Switches for Host to SIB connections can be made. 

• Cable lengths are assumed to be no problem. Seventy five feet is the 
current SIB to DMS Kit limit. 

Figure 4.5-5 Three Kit Local Host Partial DMS Layout shows a design that is 
between the two end point designs, the all DMS Kit and CBR designs. This design 
solves the problem of migrating simulations from simulated DMS to the real DMS Kit 
environment in the module trainers with a minimum of switching and cable length 
design risk. 

The final three kit design, shown in Figure 4.5-6 Three Kit Local Host PTT Kit is 
a look at spreading the three available kits among three functions (Module Training, 
PTT Training, and IT&V) rather than two (Module Training & IT&V) as was done in the 
previous designs. This design also mitigates the problem of migrating simulators from 
non-DMS PTTs to the DMS Kit environment. However, utilizing one DMS Kit between 
the two module trainers, due to the required switches, presents a high degree of 
design risk. 

If the requirements for flight equivalent payloads and payload flight software 
support are reduced from 40% to 33%, a second 5 Kit design with one DMS Kit for 
nine PTT racks, and one Kit for development is possible. This design is illustrated in 
Figures 4.5-7 and 4.5-8. Serious disadvantages of this design are that: 

• The two US payload PTT sessions would be non independent. 

• If the one US PTT kit failed, 1 00% of the PTC facility US PTTs would be down. 
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Figure 4.5-1 Eight Kit Local Host Design 
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Figure 4.5-2 PTT Racks Driven by One DMS Kit & Non-DMS Hosts 
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Figure 4.5-3 PTT Racks Driven by One Large DMS Kit 
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Figure 4.5-4 Three Kit Local Host All DMS Kit Layout 
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Figure 4.5-5 Three Kit Local Host Partial DMS Layout 
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Figure 4.5-7 Five Kit Local Host Design with Development Kit 
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Figure 4.5-8 PTT Racks Driven by One DMS Kit 
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APPENDIX A - SYSTEM SIZING ANALYSIS 

The basic method and assumptions used to derive estimates of SCS design 
computing resource requirements are outlined in this appendix. Computing resources 
were estimated for the computational processing and communications necessary to 
support the basic SCS functions. 

Loadings on the SCS LAN and the trainer LANs are expressed as kilobits per 
second (Kbps) of input from the various hosts and processors. Process loadings on 
the hosts, themselves, are expressed as millions of instructions per second (MIPS) for 
the SCS functions (application and operating system software). 

1 .0 PTC Configuration and Use Assumptions 

In order to determine rough order of magnitude (ROM) estimates for the SCS, 
several assumptions about PTC usage and configuration were made. These 
assumptions are based on analyses performed during the study, and documented in 
the Study Analysis Report, and a wide range of SSF information gathered over the 
course of the study. The report reflects the known SSF and PTC expectations held by 
NASA during this analysis phase. 

1.1 User Load on Physical Facility 

Number of people simultaneously trained in Consolidated Increment Trainer: 

Number of people simultaneously trained in each of the three Combined Trainers: 

A 

Number of people simultaneously trained in each of the nine Part Task Trainers: Z 

Number of people simultaneously trained in the Attached Payload Trainer: 1 

Number of people simultaneously trained in each of the seven POIC Trainers: Z 

Number of people simultaneously trained in the CBT Trainers: £ 

Number of people simultaneously trained in the entire PTC: 4£ Note: This sum 
does not equal the sum of all the Trainers since there would never be 100% 
utilization of all Trainers. 

Number of instructors in the PTC: 15 

Number of simulation developers: 100 

Number of integration and test personnel: 1£ 

(could also be the proportion, at any one time, of development personnel 
engaged in IT&V tasks) 
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Number of support personnel: 15 

Total number of people who work or train in the PTC at one time: 12Q 
1 .2 Number of Payloads per Trainer 

Total number of experiments in the Consolidated Increment Trainer: Z2. (US 
Lab 36 + Columbus Lab 16 + JEM Lab 16) 

No. of simultaneous experiments in the Consolidated Trainer: 4fi 

It should be noted that while there will likely be more experiments in concurrent 
operation on the Space Station than this number, there will not be more than four crew 
members on duty at any time. The other operating experiments do not require 
simultaneous operator intervention. In addition, while the other experiments do 
represent a load on Space Station resources, it is not necessary to model that load at 
a high fidelity in the PTC. (The load of the other experiments will be represented at a 
low fidelity). It should also be noted that the total number of experiments and the 
number of simultaneous experiments includes an appropriate proportion of attached 
payloads. 

Total number of experiments in the Combined Trainers: US Lab 36, Columbus 
Lab 16, JEM Lab 16 

No. of simultaneous experiments per lab: 24 USA 

12 Columbus 
12 JEM 

Total number of experiments in each Part Task Trainer: 4 

No. of simultaneous experiments in Part Task Trainer: 1 

Total number of experiments in Attached Payload Trainer: 1 

No. of simultaneous experiments in Attached Payload Trainer: Z 

Number of concurrent tests in IT&V : fi 

Number of experiments per processor (SDP, MDM): 1 

Percentage of experiments trained on with flight equivalent hardware: 1 

Payload software models will be developed and used for training for 90% of the 
experiments. 


2.0 General Assumptions about SCS Functions 
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The estimates included in this section are based, in part, on study analysis task 
T-l Scope of Payload Crew Training in PTC, Report Volume 6. Where appropriate, 
the host computer loading results reflect the overhead MIPS required by a 
multitasking/multiprocessing operating system. 

LAN loading values were derived from estimates of the maximum average 
message/packet lengths and their frequencies. The message/data traff'Cjs divided 
into real time and non-real time functions. Given that real time and non-real time 
functions occur at separate times in the PTC, the larger of the two estimates was 
selected as the bandwidth requirement. 

The Host MIPS reflect the estimated CPU power required to accomplish the 
associated SCS function. The US Combined Trainer was used as the based for all 
calculations. 

Processing requirements for the SCS trainer and support facility functions have 
been estimated, in part, by comparison to known requirements for similar functions ; in 
real time and support systems previously developed and deployed by Grumman. 
Comparable real time systems include flight simulators, ship handling simulators, test 
stands, and command and control systems. Support systems include system and 
application programming environments for these real time facilities and for large M S 
installations. Where possible, comparable program size in terms of lines of code and 
rate of repetition is used as the estimator. Otherwise, the size of the computing 
resources dedicated to the similar function is used as the estimator. Interpolation was 
used to scale the estimates when necessary. 

2.1 DMS Representation 

2.1.1 Assumptions 

We assume the estimates included in study analysis task T-1 , Scope of Payload 
Crew Training in PTC, Report Volume 6, reasonably portray the code sizes of payload 
models. These estimates are higher level language code such as Ada. For 
conversion to host loading MIPS, one line of Ada code is assumed to generate 
approximately 10 CPU instructions. 

For purposes of the sizing analysis, it was assumed that SCS simulation 
functions do not cycle at greater than 10 times per second, and that some functions 
such as payload operations may cycle less frequently (e.g., two times per second). 
Correspondingly, iterative software modules were assumed to repeat 10 times per 
second, or less as noted. These rates afford a background temporal resolution of 10 
hertz which is believed, for training objective purposes, to yield more than adequate 
fidelity. 

2.1.2 Processing Requirement 

DMS representations are accomplished in two ways: 1) by DMS Kits; and 2) by 
custom software on trainer hosts and other hardware. The DMS Kit components and 
their processing capacities are fixed by the SSF program and can not be treated as 
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SCS design variables. Since the Local Host and Shared Host designs employ DMS 
Kits, these trainer computing resources are predetermined and are not in c uded the 
the sizing analysis. However, where non-DMS solutions are used, such as NON-DMS 
Part Task trainers and the DMS Equivalent SCS design, the host processing loads are 

represented. 


The estimates included in the analysis are based, in part, on study analysis task 
T-i Scope of Payload Crew Training in PTC, Report Volume 6. Where appropriate, 
the host computer loading reflects the additional CPU processing required to support a 
multitasking/multiprocessing operating system. 


The T1 study estimates that DMS software processing for Core systems 
functions, OMA, and DMS standard services requires 48,200 lines of code. This code, 
assumed to execute at 4 hertz, was projected to require an additional 55 percent 
overhead for the operating system. 


The portion of this estimate attributable to software model representation of 
OMA and DMS services was taken to be 25 percent, with the remaining 75 percent for 
Core systems representation. Thus, 25 percent of 48,200. or 12,050, lines of code was 
used to estimate the DMS and OMA function requirements. In contrast to the T-1 
Study the code was assumed to execute at the full background frequency of 10 hertz 
to insure a capability for high system fidelity. Further, the overhead for the operating 
system was assumed to make up only 20 percent of the total processing load. 


Based on the above, the processing requirement for DMS representation is 
equivalent to: 


12,000 lines of code for DMS and OMA functions 
X 10 instructions per line of code 
X 10 hertz (cycle rate) 

X 1 .25 overhead (20 percent of total) 


1.5 MIPS 

This estimate of host loading applies to all trainers where DMS representations 
are modeled with custom software and hardware. 

2.1.3 Communications Requirement 

Communications requirements impacting the LAN loading stem from the TGU 
data stream is implemented without the dedicated DMS timing bus (TDB). The 
maximum LAN loading is estimated on a maximum timing message size of 60 bytes 
being broadcast once every 100 msec: 

60 byte message 
X 8 bits per byte 
X 10 hertz resolution 


4.8 Kbps of bandwidth = approx. 5 Kbps. 
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2.2 Core Systems Representation 

2.2.1 Assumptions 

Even though DMS designs may employ some flight equivalent Core software, 
substantial Core systems modeling will still be necessary. 

2.2.2 Processing Requirement 

Of the 48,200 lines of code estimated in the T-1 study, 75 percent is taken to 
represent Core system models. This is equivalent to approximately 36,150 lines of 
code. The required processing resource to preserve a temporal resolution of 10 hertz 
is, thus: 

36,150 lines of code for Core models 
X 10 instructions per line 
X 10 hertz 

X 1 .25 overhead (20% of total) 

4.52 MIPS = approx. 5 MIPS 

In the Consolidated trainer, 1 MIPS was added to support the additional 
requirements of the JEM Lab and Columbus Lab. 

2.2.3 Communications Requirement 

The LAN loading that results from Core system representations was estimated 
to take the form of a broadcast message with an average length of 50 bytes transmitted 
at a frequency 10 hertz. This translates to 4 Kbps of bandwidth loading on the SCS (or 
Payload) LAN. 

In the DMS Equivalent design, the bandwidth estimate was increased by a 
factor of 8 (to 32 Kbps) to accommodate message lengths up to 400 bytes that may be 
necessary for the total substitution of DMS components. 

Both estimates are based on comparisons to similar real time simulation 
functions associated with flight and ship handling training simulators. 

2.3 C & T Systems Representation 
2.3.1 Assumptions 

The aggregate science data downlink telemetry stream of all experiments is 
comprised of payload data borne by the Payload LAN and by the High Rate Link. 
When the aggregate stream must reflect a high bandwidth, it is typically modeled using 
a static, preformed data stream to augment the small dynamic data stream taken from 
the Payload (or Trainer) LAN. This latter stream may also include all uplink payload 
commands and downlink Core systems data and health and status responses 
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aenerated bv the models and flight equivalent instruments. It is assumed that, overall, 
High Rate Link data is generated by only five percent of the payload representations. 

When a dynamic, full bandwidth downlink telemetry streamla i °^® r 
to feed the POIC and/or the POIC Trainers, a separate, dedicated C&T processor 
platform will be used in conjunction with an SCS lab trainer. It is assumed, howev , 
thlt onTy^ne trainer interacts dynamically with the POIC or the POIC Trainers at the 

same time. 

The Space Station science data component of the telemetry downiink is greater 
than 100 Mbps but will not typically be more than 150 Mbps. The PTC will 
implement, simultaneously, more than one dynamic data stream of this magnitude. 

2.3.2 Processing Requirement 

The C&T function is implemented at two levels , Producing: 1) a 
bandwidth dynamic telemetry stream (but with a preformed full bandwidth sta tic 
stream); or 2) a full bandwidth dynamic telemetry stream suitable for driving the POIC 

or its equivalent. 


Basic Model 

The basic trainer C&T representation is a software model capable of: 1) 
simulating the general telemetry environment and communication system contro , and 
2) emulating, at a greatly reduced capacity, the fundamental C&T telemetry functio 
packet assembly and disassembly (PAD). 

While the code required to perform conversion and PAD-like functions can be 
complex, only a small portion of the code is used in a repetitive fashion to sustain a 
transmission This subset of code was taken as the basis for estimating the throughput 
p™e™sm£ requirement. To provide a moderate capacity real time dynamic link, a 
1 ,000 hertz cycle frequency was used. 


80 lines of repetitive code 
X 10 instructions per line 
X 1000 hertz 
X 1 .25 overhead 


1 MIP required for 10 Mbps C&T processing 

The PAD requirement of 1 Mip provides for a real time, dynamic C&T link of 10 

Mbps. 

The processing load for the communications control function was estimated on 
the basis of comparable existing code. The anticipated program size of 800 lines of 
repetitive code was used in the calculation. 


800 lines of repetitive code. 
X 10 instructions per line 
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X 10 hertz 

X 1.25 overhead (20% of total) 

1 MIPS 

The resulting total basic C&T model requirement is estimated to be. 

1 MIPS (PAD) + 1 MIPS (control) = 2 MIPS. 

Dedicated C&T Processor 

The C&T processor/adapter performs the necessary communication processing 
to output a high fidelity telemetry data stream with a high bandwidth of greater than 
100 Mbps. Multiple processors can be combined to achieve even higher aggregate 
bandwidth telemetry data streams. 

The computing resource estimate of the required CPU processing MIPS is based on a 
program containing a small module for the bulk of the sustained PAD-like 
communications processing: 

80 lines of repetitive code 
X 10 instructions per line 
X 10,000 hertz 
X 1.25 overhead 

10 MIPS 

2.3.3 Communications Requirement 

C&T processing imposes no additional load on the existing LAN traffic in any of 
the SCS designs. Generation of High Rate Link data when the flight equivalent 
payload instrument is not used, however, does yield an additional load as described in 
Section 2.18.3 Audio and Video System. 

2.4 Payload Representation 

2.4.1 Assumptions 

Payload sizing was based on the results of the T-1 Study which are assumed to 
reflect reasonable maximum payload models sizes. 

The control of several concurrent payloads presents a significant load on the 
operating system. This extra processing requirement for real time concurrency control 
is reflected in the estimates provided for the Simulation Executive function. 

2.4.2 Processing Requirement 

The temporal resolution (cycle time) required for payload models varies widely 
depending on the nature of the payload experiment and the fidelity of the payload 
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model necessary to meet training objectives. The maximum fidelity or resolution that 
can be supported, without loss of precision, is equal to the background (DMS, Core, 
and C&T) processing rate of 10 hertz. The minimum resolution suitable for a payload 
model could be as low as several seconds or minutes per iteration (cycle). 

An average, high fidelity resolution of 2 hertz was used to determine the 
processing requirements. 

Size of Payload Models - T-1 Study 

The payloads have been classified as complex, medium, and simple. The lines 
of code required for each type were estimated for: 

a complex model as 34,700 lines of code, 
a medium model as 22,000 lines of code, 
a simple model as 7,150 lines of code. 

In the extended analysis for detailed SCS design, the distributions of the 
experiment models was biased toward the complex side in order to insure maximum 
capacity. The mix of model types was assumed to be: 

Complex - 30% Medium - 30% Simple - 40% 

Based on this mix, the average module of code executed repetitively is 
estimated at 20,000 lines of code. 

The CPU processing requirement for the payload model of this size is: 

20,000 lines of code 
x 1 0 instructions per line 

x 2 hertz update rate 

x 1 .25 overhead (20% of total) 


0.5 MIPS per payload model 
2.4.3 Communications Requirement 

The communications requirements for payloads vary based on the experiment’s 
data acquisition and control profiles. The impact considered in this section is limited to 
the science and the health and status output which places a load on the Trainer or 
SCS LAN. Many of these data streams may be lower than 1 Kbps on the average. 
The base rate used in this analysis for active payloads was .5 Mbps which, when 
summed for the number of simultaneous payloads, represents the instantaneous 
maximum to be expected for a lab trainer. 

For example, 12 simultaneous experiments in a Combined trainer times .5 
Mbps equals a total maximum load on the Shared Host SCS LAN of 6 Mbps. 

When payload science data is selected and routed for monitoring, such as 
during instructor monitoring in the Local Host design, the data stream from each 
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selected payload is assumed not to exceed 2 Mbps The corresponding impact on 
LAN loading is described in Section 2.1 1 .3 Instructor Control and Monitonng. 


2.5 Environment Representation 


2.5.1 Assumptions 

Environment models are necessary to sustain DMS, payload, and Core system 
functions, and to structure training session simulation scenarios. 

The implemented fidelity of environment models varies with the type of SCS 
trainer. 


2.5.2 Processing Requirement 

It is estimated that full environment models providing adequate fidelity for the 
the Combined and Consolidated trainers will account for 24,000 lines of code. Since 
environment models are part of the matrix driving payload instruments and models, 
they must be able to execute at the background frequency of 10 hertz. 

The resulting maximum CPU processing requirement is: 


24,000 lines of code 
x 10 instructions per line 
x 10 hertz 
X 1 .25 overhead 


3 MIPS 


2.5.3 Communications Requirement 

The communications requirement associated with the environmentmodels was 
estimated on the basis of a single LAN broadcast message at the maximum 
backaround rate of 10 hertz. These messages could represent space, space station, 
and ground environment variables and relied systems data. The average message 
was assumed to contain 100 four byte variables. 

The resulting load on the SCS or Trainer LAN is: 


100 environmental variables 
X 4 bytes long 
X 8 bits per byte 
X 10 hertz 


32 Kbps 

2.6 Crew Interface Representation 
2.6.1 Assumptions 
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MPAC usage is distributed accordingly: 

Consolidated Increment Trainer: 2 USA, 1 JEM, 1 Columbus 
Combined Trainer: 2 USA , 2 JEM , 2 Columbus 
Part Task Trainers: 1 

Audio and video I/O is not considered in this analysis because these data 
streams are isolated from SCS design LANs. The streams are both internal to the 
console and sourced from a separate Audio and Video System over dedicated 
communications links which are independent of the SCS and Trainer LANS. 

Experiment displays available on the flight MPAC are simulated with high 
fidelity. 

The switches and indicators on the Control and Display Panel may be 
simulated at a medium fidelity. 

2.6.2 Processing Requirement 

It is assumed that a windowing environment and local array processing will be 
required of the crew console to provide realistic interactive graphics. In conjunction 
with requirements for peripheral I/O including video, it is estimated that the function 
requires a workstation with a minimum of 5 MIPS CPU power. 

2.6.3 Communications Requirement 

LAN loading estimates for the MPAC and its non-DMS equivalent are based on 
a maximum expected command stream output represented by the interaction of a 
position controller such as a joy stick. A data rate of 50 Kbps was used. 

2.7 Simulation Executives 

2.7.1 Assumptions 

The Simulation Executive is responsible for essentially all real time simulation 
control and coordination within a trainer. This includes the orchestration of payload 
models, DMS, Core systems, SIB, instructor interfaces, performance recording, and 
interfaces with network control programs during a training session. 

Each trainer has its own Simulation Executive. 

2.7.2 Processing Requirement 

The Simulation Executive’s real time function is required to interact with the 
trainer systems at the background frequency of 10 hertz. The scope of the executive 
requires substantial software support. Based on similarity to other complex real time 
systems, the total program size is estimated to be approximately 20,000 lines of code. 
It is estimated that the repetitive code module necessary to support a single function, 



TRW-SCS-90-XT2 Baseline Architecture 146 


such as an active payload model or a monitoring/recording activity, is approximately 
1 ,000 lines of code. 


On the average, it can be expected that approximately 20 active payloads and 
other simulation functions can occur simultaneously in a full fidelity labtramer. n 
order to span these concurrent events, the equivalent of one repetitive code module 
must be executed for each function. 


Therefore, the repetitive, time sharing nature of a Simulation Executive is 
expected to require: 


20 concurrent functions 
X 1 ,000 lines of code 

X 1 0 instructions per line 

X 10 hertz 

X 1 .50 overhead (40% of the total) 


3 MIPS 

The operating system overhead appears higher in these estimates because of 
the high sustained level of concurrency necessary to execute the simulation. The 
Simulation Executive code is also responsible lor the 

models with the trainer and SCS system components. Much of this processing 
invokes operating system resources. 


2.7.3 Communication Requirement 


The communications requirement necessary to control payload 
been estimated to range from 1 to 1.5 Kbps per payload model, 
provides for ten 12 byte command messages per second per payload. 


operations has 
This bandwidth 


2.8 POIC - DMS Interface 


2.8.1 Assumptions 

The POIC-DMS interface can be represented by both a real time interface to the 
POIC (or a POIC Trainer) and a ground control model running in the trainer host. 

The POIC-DMS Interface is assumed to interact with the OMA or equivalent 
models on a real time basis. Uplink commands and responses are modeled fully. 

A trainer's modeled telemetry stream includes Core systems data, Payload LAN 
data High Rate Link science data, and audio communications. These data are, in 
turn, ’reacted to by the modeled POIC ground systems. 
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2.8.2 Processing Requirement 

The size of the POIC-DMS interface model was estimated at 8,000 lines of 
code. This translates to 1 MIPS of CPU processing power. 

The 1 Mip computes as follows: 

8,000 lines of code 
x 10 instructions per line 
x 10 hertz 
x 1.25 overhead 

1 MIPS 

An additional 1 MIPS was added to the Consolidated trainer to support the 
requirements of the JEM Lab and Columbus Lab. 

2.8.3 Communications Requirement 

The communication requirements for the POIC - DMS interface are based on a 
maximum expected command stream output represented by the interaction of a 
position controller such as a joy stick. A data rate of 50 Kbps was used. 

2.9 PTC -POIC Link 

2.9.1 Assumptions 

It is possible, with the aid of the C&T processor box, to connect the PTC directly 
to the POIC or a physical representation of it. In these cases, it is assumed that only 
one trainer interacts dynamically with the POIC or POIC Trainer. 

The Space Station Science data components of the telemetry stream downlink 
is greater than 100 Mbps but will not be typically more than 150 Mbps. The PTC will 
not implement at any given time more than one dynamic data stream of this 
magnitude. 

2.9.2 Processing Requirement 

The processing requirements associated with PTC-POIC link parallel that of the 
C&T communications processor. The processor, under the control of the Training 
Session Manager host and coupled with a high speed LAN or telecommunications 
link, provides the computing resource for this function. 

C&T Dedicated Processor 

This processor and adapter supports a C&T telemetry link of greater than 100 
Mbps. Multiple processors can be used to achieve still higher aggregate capacity 
communications link. 
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The CPU processing power required is estimated on the basis of a small, 
rapidly cycling module of code serving as the core of this function. Consequently: 

80 Lines of repetitive code 
X 10 instructions per line 
X 10,000 hertz 
X 1 .25 overhead 


10 MIPS 

2.9.3 Communications Requirements 

The PTC - POIC represent no communications load on the SCS LAN. 

2.10 GSE Control 


2.10.1 Assumptions 

Ground Support Equipment (GSE) is a simple model which supplies control 
signals to GSE control devices or payload stimulators, or simulates ground support 
equipment functions in order to furnish parameter values to payload models. 

Ground Support Equipment is external to the SCS within the PTC. 


2.10.2 Processing Requirement 

The necessary GSE fidelity in terms of temporal resolution will vary with the 
nature of the payloads and the models implemented to meet training objectives. The 
resulting CPU processing requirement is expected to be quite modest. Based on a 
total repetitive code of 4,000 lines executing at an average cycle rate of 2 hertz, the 
estimated requirement is: 


4000 lines of code 
X 10 instructions per line 
X 2 hertz 
X 1.25 overhead 


.1 MIPS 

2.10.3 Communications Requirement 

The communications requirement per payload is based on the amount and 
frequency of control data used to drive the GSE device or the payload stimulator. 

The estimated 0.5 Kbps is derived from an expected 30 bytes of command data 
per payload recurring at 2 hertz. 

2.11 Instructor Control and Monitoring 
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2.11.1 Assumptions 

Instructor Stations are located on the SCS LAN. 

Trainer audio and video are feed to and from the Instructor Stations via the 
separate Audio and Video System. 

An Instructor Station may be used to monitor more than one (and up to four) 
trainers, crew consoles, or separate payloads at the same time. 

2.11.2 Processing Requirement 

In each of the SCS designs, the instructor stations were implemented as 
individual workstations. The workstation needs to be capable of supporting the 
operating system and file transfers, the windowing environment, multiple active 
processes in separate windows, local administrative processing, and control of audio 
and video equipment. It was determined, from known performance with similar 
tasking, that a high end workstation of approximately 16 MIPS is required. 

2.11.3 Communications Requirements 

The Instructor Station consoles are assumed to be a source of command 
streams into the trainers equivalent to the output of a position controller, or a 
parameter array for dynamic adjustment of simulation scenario events. A data rate of 
50 Kbps was used. 

Data traffic from the trainers to the consoles for monitoring functions differs 
among SCS designs. It has been assumed elsewhere that the maximum average 
data output of a payload onto the Payload LAN (not High Rate Link data) is 1.5 Mbps. 
To insure adequate monitoring capacity for payloads above this average, a 2 Mbps 
stream is assumed in this analysis. Further, this 2 Mbps may be the filtered result of an 
even larger payload data stream, when necessary. 

In the Shared Host design, the full data stream is already on the SCS LAN 
when the payload source is a model (running on a shared host). 

If, on-the-other-hand, the data originates from a flight equivalent instrument, the 
full payload data stream is routed through the SIB onto the SCS LAN. This presents 
an additional loading on the SCS LAN as shown in Figure 3.4.1 -3. It is assumed that 
in these cases, the PTC/SCS-wide maximum number of payloads being viewed 
concurrently by instructors is 10 and that the data streams are filtered down to 2 Mbps, 
if necessary. 

The presence of the trainer host(s) in the Local Host and DMS Equivalent 
designs, permits the payload data stream to be filtered to provide just what data can be 
displayed as a whole on an Instructor Station console. The resulting data stream used 
is 300 Kbps per concurrently viewed payload. 
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It should be noted that these loadings do not reflect audio and video signals 
which, in all SCS designs are routed directly to the consoles by a separate Audio and 
Video System which does not use the SCS or other LANs. 

2.12 Training Session Manager 

2.12.1 Assumptions 

Trainer hosts have local disk which support virtual memory swapping, operating 
system requirements, training scripts, code management, and all required data bases. 

In two of the three design, the TSM receives training results from the transfer in 
a non-real time mode. The exception is the Shared Host design where training result 
are transferred in real time. 

The Training Session Manager coordinates and controls instructor interactions 
with the Simulation Executives. 

The training Session Manager controls all external communications with the 

PTC. 

Training analysis and data base functions reside on the Training Session 
Manager Host. 

2.12.2 Processing Requirements 

The TSM's function is comprised predominantly of non-real time tasks 
associated with the configuration and setup of the trainers and interfacing with the 
management of training data. (Actual training data analysis and management tasks 
are covered later as separate functions). The computing resource host loading for the 
TSM is estimated to be 3 MIPS as indicated, for example, in Figures 3.3.3-1 and 3.5.3- 
1. The estimate is based on engineering judgement for an acceptable response time 
for complex tasks across several independent trainers and facilities. 

2.12.3 Communications Requirements 

The Training Session Manager produces some loading on the SCS LAN during 
both real time and non-real time operations. During real time operation, the TSM 
interacts with Instructor Stations to set up basic transaction sessions between the 
instructors and one or more Simulation Executives. The TSM also monitors the basic 
status of each Simulation Executive/Trainer. 

The LAN loading estimated at .14 Kbps per instructor station represents the 
passage of infrequent commands to the Simulation Executives and includes status 
data flowing the other direction. 

The maximum non-real time loading on the LAN during configuration and setup, 
assuming all trainers are prepared at the same time, is summarized in Figure A-1 . 
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Estimated 
Mbytes 
Per Trainer 

Total 

Mbits 

Per Trainer 

Transfer 

Rate 

Mbits/sec 

Minutes 

to 

Transfer 

Consolidated 

27 

216 

3 

1.2 

Combined 

27 

216 ”j 

3 

1.2 | 

Part Task 1 

63 ] 

504 

3 

2.8 

CBT 

5 

40 1 

3 

0.22 

POIC 

50 

400 

3 

2.22 

Totals 

172 

1376 

3 

7.64 


Figure A-1 . Configuration and Setup Analysis 

1 . Goal was to configure the PTC in under 1 0 minutes. 

2. The Development Facility and TSM will load SCS l_AN. 

3. Trainer response to transfer is minimal. 

4. Sizes of application from T-1 Study. 


2.13 Operator Control and Monitoring 


Operator Control and Monitoring functions are performed on system consoles 
that reside on the various SCS hosts. Operator functions consist pnmanly of non-real 
time functions and no not require additional processing power, or contnbute to the 

network loading. 


2.14 Configuration and Setup 

The bulk of the processing associated with this function is performed as part of 
the TSM function and has already been included in those estimates. 


2.15 Training Analysis 
2.15.1 Assumptions 

Training Analysis is supervised by the Training Session Manager in a non-real 
time mode. 


2.15.2 Processing Requirements 

In addition to Training Session Manager supervision, host support of training 
analysis includes processing for descriptive statistics, multivariant inferential statistics, 
and plots and graphs. These tasks can be implemented with COTS software 
packages. Custom software would support (but not concurrently) the analysis of 
scenario session recordings to abstract meaningful data for submission to the statistics 
packages The CPU processing load estimated to perform these functions within a 
reasonable time frame is 4 MIPS for application code and database operation. 
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2.15.3 Communications Requirements 

There is no communications requirement beyond the transfer of training data 
achieved in the Training Data Management function, described in the next section, that 
would impact the SCS LAN loading. 

2.16 Training Information Management 

2.16.1 Assumptions 

Training data are collected in real time via the Simulation Executives and 
transferred to the Training Session Manager for record keeping and administration. 
These data are also submitted to, and the results received from, the Training Analysis 
function described above. 

2.16.2 Processing Requirements 

In addition to Training Session Manager supervision, host support of training 
information management includes all data base functions and report generation. 
These tasks would be implemented with COTS software packages. Custom software 
would support (but not concurrently) the capture and storage of scenario session 
recordings. The CPU processing load estimated to perform these functions within a 
reasonable time frame is 4 MIPS for application code and database operation. 

2.16.3 Communications Requirements 

SCS LAN loading is based on the following estimates: 

3.000 records of 80 bytes per student in Consolidated and Combined trainers. 

1 .000 record of 80 bytes per student in the Part Task trainers and CBT trainers. 

Average of two minutes allowed to transfer data from trainers. 

When multiplied by the number of trainers and students, a total of 47,360 Kbits 
needs to be transferred. A composite transfer rate of 550 Kbps enables the data to be 
transferred from all trainers in approximately 2 minutes. The calculations are 
summarized in Figure A-2. 


Trainer 

Type 

Records 

Per 

Student 

Bytes 

per 

Record 

Kbits 

per 

Student 

Number 

of 

Students 

Number 

of 

Trainers 

Total 

Kbits 

Required 

Transfer 

Rate 

Kbits/sec 

Minutes 

to 

Transfer 

Consol. 

3000 

80 


4 

1 

7,680 

200 

0.64 

Combined 

3000 

80 

1.920 

4 

3 

23.040 

200 

1.92 

Part Task 

1000 

80 

640 

2 

9 

1 1 .520 

100 

1.92 

CBT 

1000 

80 

640 

8 

1 

5.120 

50 

1.71 

Totals 

8000 

80 

5120 

CD 

14 


550 

1.92 


Figure A-2. Training Results Transfer Analysis 
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Goal was to keep transfer time for training results under two minutes. 


2.17 POIC Personnel l/F 

The PTC includes seven POIC trainers. Each trainer supports a host and two 
workstations. The host processes and controls all uplink and downlink exchanges 
and provides disk storage capacity to the workstations. 

Each of the seven POIC trainers includes a host and two workstations. The 
workstations support a windows environments and connections to the Audio and 
Video System. 

The processing requirements estimated for a POIC Trainer are: 

POIC host . 8 MIPS 

Workstation... 4 MIPS *2 = 8 MIPS 


16 MIPS 

The host requirements stem from: 

C&T processing 5 MIPS 

File Server, OS, Sim Exec 3 MIPS 

4 MIPS is a small workstation capable of supporting graphics, windows, and 
operating systems. 

2.18 PTC External Interfaces 

The joint combined training mode with JSC is not specified. For this reason, 
there is no requirement for real time data interchange between the SSTF and the PTC. 
File transfers between the SSTF and the PTC are supported. File transfers between 
the PTC and the Pis are supported. 

2.19 Audio and Video Systems Representation 

An Audio/Video Processor/Controller is used to augment the Trainer Host. 

Five percent of all payload models require A/V generation. 

Additional communications processing is required to support High Rate Link 
data creation when the flight equivalent instrument is not used. The High Rate Link 
function of the corresponding payload model generates the command stream that 
drives the actual source device (of telemetry data stream), such as the Audio and 
Video System. This specialized device then generates the actual High Rate Link data 
stream for feed to the facility's dedicated C&T processor, and on to the POIC or POIC 
Trainer link. 
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The additional processing requirement was estimated as the maximum for a 
single payload model, recalling that only five percent of the payloads are expected to 
generate High Rate Link data. Basing the maximum estimate on a computer 
generated imagery requirement of one command statement (18 bytes) for every 
Kilobyte of video data, and a maximum High Rate Link output for a single payload of 
40 Mbps, results in: 

18 bytes (command) 

X 8 bits per byte 
X 5,000 kilobyte units of video data 
(for an 80 Mbps stream) 


0.72 Mbps = approx. 0.75 Mbps LAN loading 

In the example of one full fidelity Combined lab trainer with two simultaneously 
active HRL payloads, the total LAN loading for that trainer is 1 .5 Mbps. 

2.20 Primary Instruction Delivery 

The SCS facilities, including the CBT Facility, were designed, configured, and 
sized on the basis of general system architecture and engineering experience with 
similar general purpose MIS and development implementations. The basic allocation 
of CPU processing and communications resources to accommodate reasonable 
expectations for the specific functional loadings on the facility are provided in the 
following sections. 

2.20.1 Assumptions 

CBT models are of low fidelity. 

CBT models may require prerecorded audio and video inputs. 

Eight students will be training at one time. 

2.20.2 Processing Requirement 

The CBT is configured with host file server and eight disk or diskless 
workstations. The CBT file server provides data base and file services to the 
workstations as well as handle any SCS LAN request. Training results are kept on 
CBT file server and transferred to the training session manager in a non-real time 

mode. 


Based on engineering experience with comparable configurations, the 
processing load on the CBT file server is estimated to be not more than 8 MIPS. 

The processing load on the workstations, with or without local disk storage, is 
estimated to be 4 MIPS. 
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2.21 Simulation, Scenario, and DB Development 

The SCS facilities, including the SCS Development Facility, were designed, 
configured, and sized on the basis of general system architecture and engineering 
experience with similar general purpose MIS and development implementations. The 
basic allocation of CPU processing and communications resources to accommodate 
reasonable expectations for the specific functional loadings on the facility are provided 
in the following sections. 

2.21.1 Assumptions 

The facility must support 100 concurrent users in the development of payload 
models, training scenarios, and other simulation models and databases. 

A variety of workstations and graphics terminals can be used to support the 
development effort. 

2.21.2 Processing Requirements 

The SCS Development Facility has been configured to consist of 40 
workstations in total, of which 30 workstations are allocated to support the 
development of simulation models, scenarios, and database software. Thus, the 
function relies on 30 workstations at 8 MIPS per workstation for a total computing 
capacity of 240 MIPS. 

In addition, 70 MIPS of the dual file servers is allocated to support databases, 
compilers, debuggers, and multiple batch jobs. 

2.21.3 Communications Requirement 

The separate facility LAN supports virtually all communications requirements for 
the development function, and has been sized at 10 Mbps which is considered more 
than adequate to support file services under the given configuration and number of 
stations. Average response time for queries would be expected to be on the order of 1 
to 2 seconds. 

2.22 Developers Interface 

The Developer Interface function of the SCS is actually a subset of the SCS 
Development Facility described in the previous section. Additional requirements 
associated with this aspect of the facility are identified below. 

Sixty terminals connect to the host file servers via terminal servers. The 
terminals rely on the CPU processing capacity of the host file servers. The allocated 
host CPU processing requirement per terminal/user is 1 MIPS, where: 

60 users * 1 MIPS = 60 MIPS allocation. 

Similarly, the file server load for a diskless workstation is 1 MIPS, where: 
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20 Workstation * 1 MIPS = 20 MIPS. 

Twelve MIPS are allocated for expansion and additional processing support to 
the higher capacity workstations. 

2.23 Crew Interface Prototyping 

The prototyping activity for crew interfaces including C&D panels and virtual 
C&D panels is a subset of the Development Facility function. Additional CPU 
processing allocated to support specific prototyping environments takes the form of six 
workstations. Five of these 6 MIPS workstations are used as prototyping stations, with 
the sixth workstation used as a file server. 

2.24 Integrate and Test Simulations 

The SCS facilities, including the IT&V Facility, were designed, configured, and 
sized on the basis of general system architecture and engineering experience with 
similar general purpose MIS and development implementations. The basic allocation 
of CPU processing and communications resources to accommodate reasonable 
expectations for the specific functional loadings on the facility are provided in the 
following sections. 

2.24.1 Assumptions 

It is assumed that the larger, more complex payload models will require 
significantly more IT&V time, thus altering their proportion in the payload model mix 
used to set the average CPU loading. To accommodate this shift, the average 
requirement of a payload model was increased from .5 MIPS to 1 MIPS. 

It is assumed that 6 of the developers will be testing payloads concurrently. 

2.24.2 Processing Requirements 

Based on an estimate of an additional 3 MIPS to support debugging and other 
capabilities unique to IT&V tasks, 18 MIPS was allocated to the IT&V host to support 
the testing of 6 payloads concurrently. This processing capacity is in addition to that 
resident in the IT&V lab configuration unit which is equivalent to a Combined Trainer. 
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APPENDIX B - SOFTWARE SIMULATION FIDELITY LEVELS 

Level 1 Firtalitv Simulation: Level 1 fidelity simulations are simulations based on 
highly accurate mathematical representations that execute on a cyclic basis. They 
provide data values, command responses, timing, performance and user interface 
characteristics that are identical or nearly identical to those in the flight environment. 
This type of simulation uses highly accurate dynamic equations with 
appropriate cross-coupling between simulated elements. Requirements for these 
simulations are based on the characteristics of the hardware or software element to be 
simulated. These simulations provide a level of functional accuracy suitable for 
evaluating and estimating the expected performance of the flight system. Potential 
applications are performance evaluation, training, software testing, hardware 
integration/testing, problem investigation, on-orbit mission support and 
subsystem/system integration. 

Level 2 Fidelity Simulations: Level 2 fidelity simulations are simulations based on 
highly accurate mathematical representations that execute on a cyclic basis They 
provide data values, command responses, timing, performance and user interface 
characteristics that are identical or nearly identical to those in the flight environment. 
This type of simulation makes use of simplified dynamic equations with 
minimal cross-coupling between simulated elements. These simplifications are 
based on engineering approximations and heuristics ( i.e. a reduction in degrees of 
freedom). Requirements for these simulations are based on characteristics of the 
hardware or software elements to be simulated and the intended use of the simulation. 
These simulations do not allow the evaluation of the expected performance of the 
complete flight system but allow limited performance evaluation of some flight system 
elements. Potential applications are limited performance evaluation, training, software 
testing, hardware integration and testing and subsystem/system integration. 

I fivftl a Fidelity Simulations: Level 3 fidelity simulations are simulations containing 
simple relationships between stimuli/commands and responses that 
execute on an event-driven basis. They present the correct interface to the flight 
hardware/software and provide selected data values, command responses and user 
interface characteristics to an appropriate level of accuracy for the application of the 
simulation. No dynamic equations arc included in this type of simulation and simulated 
values are updated on a straight line or time delay basis. Requirements for these 
simulations are based on the appropriate interface description and the intended 
application of the simulation. Potential applications are low fidelity training, software 
testing, limited hardware integration and testing and subsystem/system integration. 

Level 4 Fidelity Simulations: Level 4 fidelity simulations are simulations that provide 
the correct interface to the fight hardware/software and create a static data flow 
load to the associated network/bus that is the same loading that would be produced 
by the flight element. These simulations provide little or no functional capability, 
no command responses and no dynamic data. Requirements far these 
simulations are based on the appropriate interface description. Potential applications 
are build up and interface testing at integration/test facilities, early prototyping and 
network/bus loading studies. This type of simulation is usually the starting point for 
simulations that require higher levels of fidelity. 
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APPENDIX C - TRAINING LOADING ANALYSIS 
Initial Estimates 

The initial estimates performed on the original study contract were based on early 
space station data and only dealt with the crew training time periods. This estimation 
was only intended to provide very rough numbers to allow some sizing analysis for the 
SCS to support the requirements of the PTC. The estimates were based on the study 
team's past training experience and generated some percentages of training for the 
different functions. The percentages are as follows: 


CBT, Payload Orientation, Class Room, 


& PI Site Visits 

20% 

PTT 

40% 

Module 

20% 

Consolidated 

20% 


These percentages were applied to the training flow and mapped to increments to 
show the concurrent training that must occur. The number of concurrent training 
sessions and their degree of independence drive the number of DMS kits, computers, 
and workstations required to accomplish payload training. The summary of this 
analysis is depicted in Figure A-1. 

Spacelab Analysis 

In order to determine more detailed estimates for SCS training, figures were 
utilized from past Spacelab experience. The Spacelab training hours could be 
correlated to Space Station for both crew training and POIC training. The estimates for 
the PI support and PTC development support were based on the current Space 
Station Program definition/schedule and our best engineering judgment. The 
following sections provide the details of this analysis. 

Crew Training 

Utilizing past Spacelab documentation (Astro-1 Integrated Training Plan) for 
Experiment/Instrument Training, the number of hours required for training per payload 
were estimated. Following are the types of training and approximate hours required 
for the Spacelab Astro mission. 



Launch Number 
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Figure A-1. Initial Training Increment Flow Analysis 

90-Day Payload lncrements/90-Day Crew Increments 
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Type of Training 

CR 

HO 

Total Hours 

Payload Orientation (PO) 

16 


16 hours 

System/Experiment Interface Training 

18 


18 hours 

Experiment/Instrument Training 




Image Motion Compensation System 

11 

4 

15 hours 

UIT 

16 

24 

40 hours 

HUT 

9 

51 

60 hours 

(+48 for new MS) ! 

48 


48 hours 

WUPPE 

4 

56 

60 hours 

(+48 for new MS) 

48 


48 hours 

Joint Operations (Combined Training for 
4 experiments) 

3 

12 

15 hours 

(+24 for new MS) 

24 


24 hours 

BBXRT 

8 

16 

24 hours 

Subtotal (Experiment/Instrument Training) 

171 

163 

334 hours 

Integrated Timeline Proficiency Training 

8 

24 

32 hours 

Simulations/Briefings 

208 


208 hours 

Total 

592 

350 

942 hours 


CR = Classroom Training HO = Hands-on Simulator Training 


Taking an average of the Experiment Training hours (IMCS[15] + UIT[40] + 
HUT[60] + WUPPE[60] + BBXRT[24]), excluding hours for new MS, yields 40 hours 
(199/5) as the average amount of training per payload. This data also shows the 
average 40 hours is broken into 10 hours of classroom training and 30 hours of hands- 
on training. As shown in the Reference Mission used in the SCS Study Analysis 
Report, there will be an estimated 43 U.S. Lab payloads per increment that require 
training. This complement is also made up of 17 complex/medium payloads and 26 
simple payloads. The Astro mission is made up completely of complex and medium 
payloads. For the purposes of this analysis, the training hours for the simple payloads 
are estimated to be half of the required hours for complex and medium payloads in 
CBT/Classroom and part task training. 

In our Study Analysis Report we determined that an equal number of experiments 
(43) will reside in the International Partner (IP) modules. Of that number we expect 
approximately 40% to be U.S. sponsored payloads. Therefore, we assume that there 
are 17 (43 X .4) U.S. payloads with the same ratio of complex/medium and simple 
experiments as in the U.S. Lab. This implies that the 17 is made up of 7 
complex/medium experiments and 10 simple experiments. 

CBT/Classroom Training 

The CBT/classroom time for SSF training can be estimated as follows: 

Payload Orientation 1 6 

System/Experiment l/F 1 8 

10 Hours per USL complex/medium payload(17) 170 
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5 Hours per USL simple payload(26) 130 

10 Hours per IP complex/medium payload(7) 70 

5 Hours per IP simple payload(IO) 50 

Integrated Timeline Proficiency 8 

Simulations/Briefings 208 

670 Hours 


Part Task Training 

The calculations for estimating the PTT hours based on the Spacelab data are as 
follows: 

30 Hours per USL complex/medium payload(17) 510 
15 Hours per USL simple payload(26) 390 

30 Hours per IP complex/medium payload(7) 210 

15 Hours per IP simple payload(IO) 150 

1260 Hours 


Module Training 

The estimation for module training hours is based on the Astro joint operations 
training and the integrated timeline training. However, we must take into account the 
complexity of payloads and the fact that the Astro experiments were tightly coupled 
since they were mounted on the IPS. Therefore, training hours for simple payloads 
are estimated at one hour for each of the two types of training. For this analysis, we 
have also assumed that the total hours necessary are approximately 15% less due to 
greater independence of the payloads. The total hours estimate is calculated as 
follows: 

Astro hands-on joint operations training was 12 hours and involved 4 exp. 

12/4 = 3 hours per experiment 

Astro integrated timeline training included 5 experiments for 24 hours 

24/5 = 4.8 hours per experiment 

1 hour is utilized in each exercise for simple payloads 

The total hours are; 

Joint Operations: 

3 Hours per complex/medium payload(17) 51 

1 Hour per simple payload 26 

Integrated Timeline: 

4.8 Hours per complex/medium payload(17) 82 



TRW-SCS-90-XT2 Baseline Architecture 162 


1 Hour per simple payload(26) 23 

185 

Subtract 1 5% due to greater independence for 
the majority of SSF payloads i2S 

157 hours 


Consolidated Training 

The SSF consolidated training is expected to resemble the Spacelab integrated 
timeline training. Therefore, we can extrapolate the data from the integrated timeline 
activities to provide an estimate. Since the consolidated training includes about the 
same number of experiments in the two International Partner modules, we will assume 
that there are 86 payloads which include 34 complex/medium and 52 simple 
experiments. However, we must also assume that there is at least 25% less 
interactions between the total number of payloads in SSF considering that they are in 
different modules. 

4.8 Hours per complex/medium payload(34) 163 

1 Hour per simple payload(52) 52 

215 

Subtract 25% due to greater independence i54 

161 hours 

Total Crew Training 

The following table summarizes the estimated training hours and the percentages 


of the total training. 

Training Hours % Qf Total 

CBT/Classroom 670 30 

Part Task Training 1260 56 

Module Training 157 7 

Consolidated Training 161 2 

TOTAL 2248 1 00 


Although these numbers can be supported by resources in the SCS, the real 
limiting factor is the crew availability. If the crew were available 100% of the time, 
there would be 2080 hours for training. Obviously, the 2244 hours estimated cannot 
be accomplished in the one year allotment for training. This estimation, except for 
consolidated, includes only U.S. payload training time. When considering total crew 
training activities, the training for the International Partner payloads must be 
considered. The same training assumptions for the SCS hour estimates can be 
applied to the remaining experiments in the IP modules. A quick estimate for the 
overall crew training hours can be calculated as follows: 
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SCS hours 2248 

International CBT/Classroom 1 80 
International part task training 540 

International module training 15Z 

Total Training Hours 3125 

15% for travel, etc. 

TOTAL HOURS 3594 

This would indicate that a 21 -month timeframe is necessary to train the crew 
members based on our training assumptions which includes a 40-hour week work 
schedule. 

POIC Training 

Estimates for POIC training are based on the Mission Independent Training 
Program Handbook for the Astro mission. Utilizing the list of courses for Mission 
Independent training, it was estimated that the Mission Dependent training was 30% of 
Mission Independent. In a similar fashion, upon calculating Line Organization Mission 
Independent training hours, it was estimated that Line Organization Mission 
Dependent training was 10% of Line Organization Mission Independent. Hours 
estimated for Self-Study are a general estimate arrived at by talking with NASA 
personnel. Approximate hours per POIC trainee for each designated type of training 
are identified below: 

Mission Independent => 307 hours 

Mission Dependent => 92 hours 

Line Organization 

Mission Independent => 16 hours 
Mission Dependent => 2 hours 

Self-Studv T raining => 1 8 hours 

Total 435 hours 

The CBT hours can be estimated as follows: 

New Personnel 

Assume 5 POIC crews of 25 personnel each 
Assume a 10% yearly turnover rate 

Assume that 75% of the above training can be accomplished with CBT 
5 X 25 = 125 total personnel X 10% = 12.5 personnel to be trained each year 
435 X .75 = 326 hours X 1 2.5 = 4075 CBT training hours/year 
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Incremental Training 

Assume 4 hours CBT per experiment 

Assume 7 experiments per 90-day increment (15% changeout) 

Assume 5 crews of 25 

125 X 7 X 4 = 3500 hours per 90-day increment 
4 increments/year X 3500 = 1 4,000 hours/year 

Any training which involves module or consolidated modes is expected to be 
accomplished in conjunction with the crew activities. Therefore, no additional SCS 
resources (other than the link to the POIC) are anticipated to support that type of POIC 
training. 

Principal Investigator Support 

Estimates for the support for the Pis include some training on SCS operations 
and hours to support to the integration and checkout of their experiment simulator. 
Based on the 15% changeout every 90 days, we can expect 7 new Pis with payloads 
for the U.S. Lab every increment and as many as 3 experiments for IP modules. 
Assume training for a 3 member PI team training concurrently. If we assume 4 hours of 
training on the SCS operations (CBT) and 2 weeks for integration and checkout of the 
payload simulator, we can estimate hours as follows: 

CBT Training per increment (10X4)= 40 hours/increment 

4 increments/year X 40 X 3 menloads in each PI team = 480 hours/year 

U.S. Lab PTT Use per increment (7 X 80) 560 hours/increment 

IP PTT Use per increment (3 X 80) 240 hours/increment 

PTC Personnel 

For this exercise, the estimates for the PTC software personnel will only incorporate 
the needs for CBTs. The software development needs for a consolidated, module, or 
part-task configuration to support testing activities will be provided in the software 
development facility identified in the SCS designs. The CBT hours estimate can be 
determined by: 

Assume 1 40 PTC personnel 
Assume a 10% yearly turnover rate 

Assume a 20 hour course on PTC overview and detailed operations for each 
new person 

140 X 10% X 20 = 280 CBT hours per year 

Also, CBT hours must be available for course development 
Assume 20 hours per experiment to support Pis and other activities 
10 X 20 = 200 hours per 90-day increment 
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Training Resource Estimate 

Based on the training hours estimated in the preceding sections, an estimate of the 
resources necessary to support those training hours can be determined. For example, 
4075 CBT training hours must be available to support POIC training for new 
personnel. Given 2080 hours available per year yields a requirement for 2 CBT 
stations to support the training of new POIC personnel (4075 + 2080) given ideal 
scheduling. Realistically, trainees will only be available 1/2 of their turn, so to fulfill the 
rest will require 4 CBT STHS. An analysis of the increment flow is also necessary to 
determine the number of crews to be trained in any particular time period assuming 
45-day and 90-day crew increments. The crew flow for a 45-day increment has been 
depicted in Figure A-2 and incorporates a 12-month PTC training period split by the 
percentages of training time from our estimates on each training function. The flow 
clearly shows the number of crew that are simultaneously involved in each training 
function. The number of trainers operating concurrently are estimated for each of the 
training functions in the following sections. 

The analysis effort did consider the fact that the station operator will not need 
the degree of training required by the other crew members. However, we determined 
that this made no impact on the need for PTTs since the PTTs support two personnel 
per session. Therefore, a crew would still require 2 PTTs to train simultaneously 
whether it was made up of 3 or 4 personnel. The total hours of CBT station time would 
be impacted, but the costs of CBTs are expected to be minimal. Since the degree of 
training for various members of the crew is still undefined and the apparent cost 
impacts appear to be very minimal, the final estimates did not incorporate any varying 
degree of training for specific crew members. 

45-Day Crew Increments 

QB1 


2 crews of 4 training simultaneously 8 

New POIC personnel 4 

Incremental POIC personnel training 7 

PI and PTC personnel support 2 

Number of concurrent CBT sessions 22 


EH 


4 crews training simultaneously (2 per PTT) 8 

PI support 1 

PTTs in concurrent use 9 
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Figure A-2. PTC Training Increment Flow Requirements (Spacelab Data) 

90-Day Payload lncrements/45-Day Crew Increments 
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Based on the number of U.S. Lab experiments (43) and the number of U.S. 
sponsored experiments in the IP modules (17), the configuration of PTTs could 
include U.S. Lab (8 PTTs for U.S. Lab payloads) and IP (2 PTTs for JEM, and 2 PTTs 
for Columbus). Some time on the PTTs must be available to support the PI activity for 
payloads in the different IP modules, but the demand for U.S. Lab PTTs indicates the 
need for an additional PTT for the PI support. Since the PTTs will be different for each 
module, this implies that a total of 13 PTTs must be available to meet the possible 
training schedules and provide available time for PI support. The total number of 
configured PTT sessions that must be available at certain times in the training 
schedule are: 

PTTs for U.S. payloads in the U.S. Lab 9 

(8 for crew and 1 for PI support) 

PTTs for U.S. payloads in the JEM 2 

PTTs for U.S. pavloa ds in the Columbus._2 

Concurrently available PTT sessions 1 3 

Note -The U.S. Lab modules for module and consolidated training are expected 
to have available time to support any overflow of individual payload training. 

Module 

Only one crew at a time will need to be trained, so only a single U.S. Lab module 
and a single Attached Payload Trainer will be necessary to support training. 

Consolidated 

Only one crew at a time will need to be trained, so only a single Consolidated 
Trainer will be necessary to support training. The Consolidated Trainer must include a 
U.S. Lab module, a JEM module, an Attached Payload Trainer, and a Columbus 
Module. Since the 45-day increment flow shows simultaneous use of a module trainer 
and a consolidated trainer, a second U.S. Lab module will be necessary. It is 
expected that the Attached Payload Trainer can be the same one used to support U.S. 
Lab module training. 

90-Day Crew Increments 

If we evaluate the needs based on a 90-day crew increment, only those numbers 
involving the crew training must be modified. The following estimates are based on 


the 90-day flow shown in Figure A-3. 

CBT 

1 crew of 4 training simultaneously 4 

New POIC personnel 4 

Incremental POIC personnel training 7 

PI and PTC personnel support 2 


Number of concurrent CBT sessions 1 8 
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Figure A-3. PTC Training Increment Flow Requirements (Spacelab Data) 

90-Day Payload lncrements/90-Day Crew Increments 
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EU 

2 crews training simultaneously (2 per PTT) 4 

PI support 1 

PTTs in concurrent use 5 

Based on the number of U.S. Lab experiments (43) and the number of U.S. 
sponsored experiments in the IP modules (17), the configuration of PTTs includes 
U.S. Lab (4 PTTs for U.S. Lab payloads) and IP (1 PTT for JEM, and 1 PTT for 
Columbus). Some time on the PTTs must be available to support the PI activity for 
payloads in the different IP modules, but the demand for U.S. Lab PTTs indicates the 
need for an additional PTT for the PI support. Since the PTTs will be different for each 
module, this implies that a total of 7 PTTs must be available to meet the possible 
training schedules and provide available time for PI support. The total number of 
configured PTT sessions that must be available at certain times in the training 
schedule are: 

PTTs for U.S. payloads in the U.S. Lab 5 
(4 for crew and 1 for PI support) 

PTTs for U.S. payloads in the JEM 1 
PTTs for U.S. pavlo ads in the Columbus 1 
Concurrently available PTT sessions 7 

Note -The U.S. Lab module is expected to have available time to support some 
overflow of individual payload training. 

Module 

Only one crew at a time will need to be trained, so only a single U.S. Lab module 
and a single Attached Payload Trainer will be necessary to support training. There will 
be available time in the module trainer to support needed time for individual payload 
training. 

Consolidated 

Only one crew at a time will need to be trained, so only a single Consolidated 
Trainer will be necessary to support training. The need for a second U.S. Lab module 
to support this will still be necessary even though there is no simultaneous operations 
expected for the module and consolidated trainers. This is due to the necessity for 
configuration time and some expected overflow of individual payload training into the 
U.S. Lab modules. 
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